ftp.cs.arizona.edu/ftp.cs.arizona.edu.tar/ftp.cs.arizona.edu/icon/newsgrp/group02b.txt/000070_icon-group-sender_Mon Oct 14 07:49:46 2002.msg

Internet Message Format | 2003-01-02 | 9KB

Return-Path: <icon-group-sender>
Received: (from root@localhost)
    by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g9EEm9w06924
    for icon-group-addresses; Mon, 14 Oct 2002 07:48:09 -0700 (MST)
Message-Id: <[e-mail]>
From: "Andrew Hamm" <[e-mail]>
X-Newsgroups: comp.lang.icon
Subject: Re: Icon Wish List
Date: Sun, 13 Oct 2002 00:46:52 +1000
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
To: [e-mail]
Errors-To: [e-mail]
Status: RO

Shmuel (Seymour J.) Metz wrote:
> [STUFF]
>

I don't think you've understood what I've said. Perhaps I'm not using the
correct terminology... let me deal with your points one by one.

>> Since Icon is completely free with variable types and call arguments,
>> it follows that class members should not be typed,
>
> No. The class is the type.
>

look at this:

    procedure thing(arg)
        local lcl

to me, "arg" and "lcl" are variables; the dynamically allocated objects
which they may refer to at any point during execution have type (traditional
Icon types being string, numerics, tables etc), but "arg" and "lcl" do not
have a declared type. Of course the allocated objects will have type; as you
say, the class will be the type of the allocated object currently referred
to by arg or lcl, but still, "arg" and "lcl" do not have a declared type and
it is contrary to the current design of Icon to declare type for these
variables - ie the named variables. Clearly the referred objects will have
class type. It does violence to Icon to suggest that variables be declared
with type, such as:

    local lcl: someClass

and to me, it follows that class members should not be declared with type
either. Neither should method arguments.... read on.

>> and overloaded methods do
>> not make sense either
>
> They make perfect sense if you allow subclasses and such.
>

I said "overloaded" not "overridden". An example of an overloaded method is:

class ClassA {
    draw(int x, int y);
    draw(Coord xy);
}

Now, objects of type ClassA may have these two calls made:

    anA.draw(10, 20);

or

    anA.draw(new Coord(10, 20)); // or equivalent

Here, the draw method is "overloaded" within the class to support different
calls providing that the argument signatures are sufficiently unambiguous
within the language rules.

In languages supporting overloaded methods, they require the argument type
and possibly the return type to be declared for the methods, and the
"signatures" of the methods must be sufficiently distinct to allow the
compiler to choose the correct method when it knows the count and types of
all the values being provided to the method call. Since Icon supports
untyped arguments, default null values for unprovided arguments, quiet
discarding of excess arguments and finally explicit variable argument lists
with the trailing arg[] syntax, it follows that Object Icon would most
naturally support one method of one name *per class* with normal Icon-style
argument declaration and invocation. However I am not saying that Object
Icon should prevent *overriding* of methods in sub-classes. I thought my
discussion clearly showed cognisance of sub-classes and *overridden*
methods.

>> one name, one method
>
> Too restrictive, and destroys some of the value of OO programming.
>

No, it doesn't. Icon currently supports variable argument lists in procedure
calls, and it's a common technique to detect the differing arguments
provided and perform a variant action depending on the arguments passed.
Further, any method which cared to handle different args differently can
easily examine the type of the arguments and choose to interpret them
appropriately. For example, C++ might require you to declare

    draw(int x, int y) { .... }

and

    draw(xy Coord) { .... }

but Object Icon can easily be coded to detect the types of the args and deal
with it accordingly. eg

    procedure draw(x, y)

        if numeric(\x) & numeric(\y) then ....
        else if type(x) == "Coord" & /y then ....
        else

OK, so that sample is not perfect, but a few minutes of real thought would
make it most usable. Sample given for illustration only.

>> What about member privacy? With the 1 file, 1 class model, it does
>> become possible to add a "private" keyword for class methods,
>> members and statics. If marked as private, the member is not visible
>> outside the file. However, that does not fit at all with the dynamic
>> typing of Icon.
>
> Yes it does. Don't confuse the scope of the name with the lifetime of
> the object.
>

Well, no it doesn't. You need to consider how it might be implemented. If
ClassA declared a private member M, but ClassB declared a public member M,
consider this situation:

class ClassC ........

procedure method1(arg)
    ....
    if arg.M > 10 then .....

now, how can the compiler determine that arg.M is legal? Depending on what
is passed in, arg.M may or may not be legal depending on the current dynamic
type of the value that arg refers to. The only way to solve this is with a
runtime check which cross-references the current dynamic type with the
visibility of M in relation to the context using it. Did you say "Bletch!" ?
I say bletch to such horrific runtime tests... I want my scripts to complete
today, thank-you very much.

>> However,
>> that does not fit at all with the dynamic typing of Icon.
>
> It fits in perfectly. All that changes is that there are more possible
> types.
>

The increased set of possible types is not related to the necessary compiler
and/or runtime code required to enforce scoping rules.

>> How do you know the type of a particular variable at any one time?
>
> The same way as in any other language with dynamic types.
>

I am aiming more for compile-type checking. I spit on runtime checking of OO
rules. If you want heavy rules, use a language which can resolve all the
nonsense at compile time. Icon has never demanded specific declarations, and
an Object Icon should retain that freedom and simplicity. It's about time
that programmers learned to respect good programming practices. I am
disgusted at the mess we lovingingly call C++ version 3 with STL and
standards approval. What a disaster, and all that legalise rubbish just
because programmers continue to be lazy and clumsy and enjoy shooting
themselves in the foot.

>> To do this "properly" on UNIX, the compiler could probably write to
>> a tmp file (not linked into a directory) and then hand the open file
>> handles off to a cooperating iconx which can slurp up the icode from
>> the tmp file handles and then close them, resulting in their
>> deallocation.
>
> Bletch!
>

I'm only suggesting a method to add

#!/usr/bin/icon

capabilities easily into Icon. Since the current implementation is neatly
split into a compiler/linker and a separate runtime, it's mere mechanics to
add #! to Icon, without requiring the merging of icont and iconx just
because "it's more elegant" to merge them, or too "bletchy" to use a dirty
trick. Why burden the runtime with the baggage of the compiler? My
suggestion is merely pragmatic, and nobody needs to see how much steam and
oil is spraying around in the engine room.

However, there is tantalising merit in allowing Icon programs to support
some kind of "eval" statement just like Perl or shells do; this would
require access to the compiler from the runtime...

Ultimately, you have to remember that Icon is very dynamically typed, very
simple in it's scoping, and it doesn't follow convention. Please let's not
burden Icon or a hypothetical Object Icon with fashionable or politically
correct ideas about how OO must be implemented. C++ has shown the folly of
designing a language to the point that only a lawyer can fully understand
all the rules. Perl has shown quite clearly that lack of enforced
encapsulation rules does not cause a mass outbreak of bugs. I've collected
dozens of classes out of CPAN and am happily using them, completely ignorant
of the internal mechanics and totally unfazed by the lack of privacy for the
class members. If I start fishing around inside the class, messing around
with class members beyond that described in the doco, then I've only got
myself to blame when my code blows up in my face. Same goes for everyone
else.